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SYSTEM AND METHOD FOR PREDICTING A MAINTENANCE SCHEDULE 
AND COSTS FOR PERFORMING FUTURE SERVICE EVENTS OF A PRODUCT 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application claims the benefit of U.S. Provisional Application No. 
60/196,815, filed April 13, 2000. 

BACKGROUND OF THE INVENTION 

This disclosure relates generally to servicing products and systems and more 
particularly to predicting a maintenance schedule and costs for performing future 
service events of a product or a system. 

Over the past several years there has been tremendous growth in the services 
business. Many manufacturers and service organizations are now offering long term 
service agreements to maintain and service repairable products and systems such as 
power generation equipment, aircraft engines, automobiles, locomotives and other 
high tech products. Typically, these long term service agreements have a multi-year 
duration that can range from 10-20 years. In addition, the long term service 
agreements have an associated liability in the millions. In order for the manufacturers 
and the service organizations to assume the risk associated with the long term service 
agreements, they must have an accurate prediction of all maintenance and service 
associated with the products or systems and their costs. 

Therefore, there is a need for an approach that can predict a maintenance 
schedule of future service events for a product or system and the costs associated with 
these events for the duration of a long term service agreement. 
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BRIEF SUMMARY OF THE INVENTION 

The system and method of the present invention predict a maintenance 
schedule and costs for performing future service events on a product formed from a 
plurality of components. The maintenance schedule and costs of the future service 
5 events are used to predict the cost and price of a long term service agreement for the 
product. A scheduler predicts the maintenance schedule based on the operating 
conditions the product is exposed to, as well as on design limits or constraints for the 
components of the system. The design limits or constraints are defined in terms of 
operating hours, based on the operating conditions, to which the sub-components of 
ClO each component are exposed. The design constraints are also defined in terms of 
•j business rules and design curves for each component and sub-component. The 

scheduler determines the operating time for each sub-component based on the 
i j operating conditions for a predetermined time period and compares it to the design 

1% limit for the component. Once a design limit is exceeded for a sub-component, the 

; 15 scheduler then schedules a maintenance event to repair or replace the component and 
its related sub-components. A simulator takes the predicted maintenance schedule 
j« and simulates the maintenance events to determine the cost of the maintenance events. 

O A aggregator then aggregates the predicted maintenance schedule and the predicted 

costs for the length of the service agreement to obtain a complete schedule of future 
20 maintenance events and a total cost representative of fulfilling the service agreement 
for the product. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic representation of a general purpose computer system in 
which a system for predicting a maintenance schedule and costs for performing future 
25 service events of a product operates; 
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Fig. 2 is a schematic representation of the architecture of the system for 
predicting a maintenance schedule and costs for performing future service events of a 
product; 

Fig. 3 is a flowchart describing actions performed by the system for predicting 
a maintenance schedule and costs for performing future service events of a product; 

Fig. 4 is a flowchart describing actions performed by another embodiment of a 
system for predicting a maintenance schedule and costs for performing future service 
events of a product; 

Fig. 5 is a flowchart describing actions performed in one embodiment of 
calculating a maintenance schedule for a product; 

Fig. 6 is a flowchart describing actions performed in one embodiment of 
calculating maintenance costs for a product; and 

Fig. 7 is a flowchart describing actions performed in one embodiment of 
simulating the service costs and risks in predicting the maintenance costs for a 
product. 

DETAILED DESCRIPTION OF THE INVENTION 

Referring to Fig. 1, a system 28 for predicting a maintenance schedule and 
costs for performing future service events on a product includes a local computer 10 
running a local prediction application 11 in communication through a network 13 with 
a server computer 15 running a server prediction application 17. The arrangement of 
the local computer 10 and the server computer 15 forms a client-server system, 
splitting tasks to be performed by the prediction system 28 between the two 
computers. A user of the local computer 10 inputs data for a product, such as 
operating conditions for a given time period, and the data is sent through the network 
13 to the server computer 15. Through the prediction application 17, the server 
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computer 15 accesses data within a database 26 that is associated with the incoming 
data in order to operate an aggregator 59 including a scheduler 60, a simulator 62 and 
an aggregator 68 to determine an output 70. The output 70 includes an aggregated 
maintenance schedule and costs, which is returned to the local computer 10 for 
display, review and manipulation. 

The local computer 10 is one of a plurality of a general-purpose computer 
systems on the network 13 in which the system 28 for predicting a maintenance 
schedule and costs for performing future service events of a product operates. The 
local computer 10 generally includes a processor 12, a memory 14, input/output 
devices, and data pathways (e.g., buses) 16 connecting the processor, memory and 
input/output devices. The processor 12 accepts instructions and data from the 
memory 14 and performs various calculations. The processor 12 includes an 
arithmetic logic unit (ALU) that performs arithmetic and logical operations and a 
control unit that extracts instructions from memory 14 and decodes and executes 
them, calling on the ALU when necessary. The memory 14 generally includes a 
random-access memory (RAM) and a read-only memory (ROM), however, there may 
be other types of memory such as programmable read-only memory (PROM), 
erasable programmable read-only memory (EPROM) and electrically erasable 
programmable read-only memory (EEPROM). Also, the memory 14 preferably 
contains an operating system, which executes on the processor 12. The operating 
system performs basic tasks that include recognizing input, sending output to output 
devices, keeping track of files and directories and controlling various peripheral 
devices. 

The input/output devices include a keyboard 18 and a mouse 20 that enter data 
and instructions into the local computer 10. A display 22 allows a user to see what 
the computer has accomplished. Other output devices could include a printer, plotter, 
synthesizer and speakers. A modem or network card 24 enables the local computer 
10 to access other computers and resources on the network 13. A mass storage device 
25 allows the local computer 10 to permanently retain large amounts of data. The 
mass storage device 25 may include all types of disk drives such as floppy disks, hard 
disks and optical disks, as well as tape drives that can read and write data onto a tape 



RD-28,035/USA 

that could include digital audio tapes (DAT), digital linear tapes (DLT), or other 
magnetically coded media. The above-described local computer 10 can take the form 
of a hand-held digital computer, personal digital assistant computer, personal 
computer, workstation, mini-computer, mainframe computer and supercomputer. 

5 The server computer 15 may include all of the same components described 

above for the local computer 10. The server computer 15 is preferably configured to 
store and process large amounts of data, however, thereby increasing the speed of the 
local computer 10. A suitable example of a server computer 15 includes a Sun Solaris 
Server Computer, as well as other servers manufactured by to run Unix or Windows- 
10 type server systems. 

The network 13 is a system that enables communications, including the 
exchange of data, among a plurality of computers. The network 13 may be a private 
communications network or a public communications network. For example, the 
network 13 may be a local area network (LAN), a wide area network (WAN), the 
15 Internet, or other similar networks. 

As described above, the system and network include a "thin client system" or 
Web system, in other words where the majority of the data storage and processing 
capabilities are within the server computer 15. Alternatively, the system may be 
configured as a "thick client system" where the server computer 15 primarily includes 
20 the data storage capabilities while the local computer handles the majority of the 
processing involved with prediction of the aggregated schedule and costs. 

Referring to Fig. 2, the server computer 15 includes the database 26 for the 
storage and retrieval of large amounts of data relating to predicting maintenance 
schedules and costs. The data within database 26 includes files having lists and 
25 tables, among other forms of data. For example, product data 30 includes data 
relating to parts list 32 that detail the components 34 and sub-components 36 that 
make up each unit or product 38 for which a service contract may be desired. The 
components 34 and sub-components 36 are assemblies, sub-assemblies and piece- 
parts that make up a finished product 38. 
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The product data 30 is associated with design constraint data 40 that includes 
design limit data 42 for each item in the parts list 32 for each product 38, The design 
limit 42 for each part assembled into product 38 is defined in terms of operating time 
44, for example in operating hours. The operating hours 44 may further be defined 
5 for a new part and for a refurbished part. Further, the design limit data 42 may 
include information on how many times a part may be refurbished or repaired before 
it is no longer considered useable. The design limit data may also include information 
on a parts' exposure to other predefined operating variables that may be particularly 
important in determining the life of the part. For examples, in power generation 

10 equipment, the number of starts a part is exposed to needs to be considered. 
Preferably, the design limit operating hours 44 are defined in a normalized unit of 
measure, thereby allowing the wear and tear associated with various operating 
conditions to be converted into one standard operating hour measure that is used to 
define the design limit of the part. To aid in determining the operating hours 44 in the 

15 normalized measure, the design constraint data 40 additionally may include business 
rules 46 and design curves 48 for each part. The business rules 46 include suggested 
maintenance guidelines for the relevant product 38. The design curves 48 include 
graphical representations of the performance of a part, in terms of operating hours, for 
a given set of operating conditions. 

20 The operating conditions data 50 is used in conjunction with the design limit 

data 42 in predicting maintenance schedules and costs. The operating conditions data 
50 includes a given set of operating conditions, applied for a given time period within 
the term of the service contract, that affect the maintenance requirements of a product 
38 for which a service contract may be desired. The relevant set of operating 

25 conditions will vary, quantitatively and qualitatively, depending on the product 38 and 
the scenario within which the product is being used. For example, the amount of time 
within the given time period that the product 38 is actually in use and the details of 
the operating environment typically are relevant operating condition variables. 
Typically, the information within the operating conditions data 50 is supplied by the 

30 owner of the product 38, but nominal or forecasted values may be utilized for 
estimation purposes. 
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Additionally, risk data 52 is associated with the product data 30, the design 
constraint data 40 and the operating conditions data 50. The risk data 52 includes a 
parts risk variable 54 and a service risk variable 56, respectively, that are associated 
with each item in the parts list 32 and each task within a service event, discussed in 
more detail below, in determining the predicted maintenance schedule and cost for 
each product 38. The parts risk 54 and service risk 56 may be used to account for 
potential variability in parts cost, service cost and parts and service reliability. The 
parts risk 54 and service risk 56, for example, may be variables that are functions of 
the part cost and service cost, respectively. For example, for a part or service having 
a relatively high variability in cost and/or reliability, the risk variables 54 and 56 may 
be multiplied by the parts cost and service cost, respectively, to result in a higher 
number in order to account for the relatively higher risk associated with the part or 
service. In general, the parts risk 54 and service risk 56 increase with the complexity 
of a part or service, i.e. the number and complexity of assemblies within a part and the 
number of procedures and parts involved in a service. 

Further, service data 58 includes details on the required tasks and parts 
involved in any maintenance event that may be predicted by the system 28. The 
service data 58 also includes the service costs associated with performing the tasks of 
the maintenance event. 

The information from data files 30, 40, 50, 52 and 58 is utilized by a scheduler 
60 and a simulator 62 to determine a maintenance schedule 64 and the associated 
maintenance costs 66 for each task in a maintenance event, preferably for the term of 
a service contract to estimate the cost of the contract. In particular, for each part in 
the parts list 32 for a given product 38, the scheduler 60 processes the set of given 
operating conditions from the operating conditions data 50 with the design limit data 
42 from the design constraint data 40 to determine the maintenance schedule 64. The 
scheduler 60 sends the maintenance schedule 64 to both the simulator 62 and the 
aggregator 68. The simulator 62 utilizes the maintenance schedule 64 in combination 
with information from the product data 30 and service data 58 to determine and output 
the maintenance costs 66. The maintenance schedule 64 and associated costs 66 are 
then compiled and aggregated by a aggregator 68 to produce an output 70, which is 
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the predicted aggregated maintenance schedule and costs for performing future 
service events on a product over the term of a service contract. 

The scheduler 60, simulator 62 and aggregator 68 are typically software 
applications, and may be a single application. Although typically software-based, 
5 these components may include software, hardware, firmware or combinations thereof. 
Further, although described separately, data files 30, 40, 50, 52 and 58 may be a 
single data file or they may be contained in separate databases. 

In operation, referring to Fig. 3, a method of predicting a maintenance 
schedule and costs of future service events of a product to be serviced under a long 
10 term service agreement includes obtaining the operating conditions for the product for 
5 a predetermined time period (Step 72). The operating conditions preferably are 

&\ obtained from the owner of the product and input into the operating conditions data 50 

K v (Fig. 2). However, the operating conditions may be input into the system 28 from 

flj other sources or the operating conditions may be estimated. Preferably, the 

' H 15 predetermined time period corresponds to the time period of the long term service 
H agreement. Additionally, the operating conditions may include a plurality of sets of 

!ii operating conditions, where each set is associated with a portion of the predetermined 

time period. For example, the operating conditions may change on a monthly basis, 
□ and therefore to analyze the maintenance schedule and cost for a year, 12 different 

20 sets of operating conditions would be obtained corresponding to each month of the 
year. 

Once the operating conditions are obtained for the product, the system 28 (Fig. 
2) determines the operating time for each part of the product for the predetermined 
time period under the given operating conditions (Step 74). As mentioned above, the 

25 operating time relates to a normalized measure of the wear and tear on, or reduced 
useful life of, the part based on the operating conditions. Further, the operating time 
is determined using the design constraint data 40 (Fig. 2) and risk data 52 (Fig. 2). 
Then, the system 28 determines the cumulative operating time of each part of the 
product since the last maintenance event (Step 76). This involves adding the 

30 operating time for the predetermined time period to the operating time of each part 
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that existed at the start of the predetermined time period. All of this data is 
maintained in the database 26. Once the cumulative operating time for each part is 
determined, then the cumulative operating time is compared to a predetermined 
design limit for each part (Step 78). The system 28 retrieves the design limit data 42 
5 (Fig. 2) for each part to determine whether the cumulative operating time for the part 
is greater than the predetermined design limit in order to predict a maintenance 
schedule. If the cumulative operating time does not exceed the predetermined design 
limit, then the system 28 may return to Step 72 to begin the analysis for another 
predetermined time period and set of operating conditions until the end of the long 
10 term service agreement is reached (Step 80). If the cumulative operating time exceeds 
the predetermined design limit, then the system 28 schedules a predicted maintenance 
■p: event to replace the part (Step 82). In scheduling the maintenance event, the system 

y 28 is able to calculate the exact time within the predetermined time period that the 

-*," part exceeds the predetermined design limit, and the system schedules the 

&15 maintenance event to occur within the predetermined time period prior to this exact 
A time. Thus, the maintenance event is scheduled prior to exceeding the design limit, 

j« t thereby avoiding a potential failure of the part and a potential failure of the product. 

;;; :s Once the system 28, through the scheduler 60 (Fig. 2), predicts the 

Q maintenance schedule over the term of the service agreement, then the system utilizes 

L " 20 the simulator 62 to predict the cost associated with the maintenance services. For 
each predicted maintenance event that is scheduled for the product, the system 28 
generates a list of parts and a list of services, and their associated cost and risk (Step 
84). The simulator 62 utilizes the service data 58, the risk data 52 and the product 
data 30 in order to analyze each part that needs maintenance, the associated parts that 
25 are affected, the related services involved in the maintenance event, and the costs and 
risks involved for each part and service task. Through the aggregator 68 (Fig. 2), the 
system 28 accumulates the predicted maintenance schedule 64 and the predicted 
service costs 66 and generates an aggregated maintenance schedule and costs, or 
output 70 (Fig. 2), for the product for the term of the service agreement (Step 86). 
30 The output 70 includes the total costs involved in the long term service agreement, as 
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well as breaking down the costs and risks down to the individual part or service task 
level associated with each particular maintenance event. 

In this disclosure, the system 28 for predicting a maintenance schedule and 
costs for performing future service events of a product will be further described with 
5 reference to power generation equipment such as a gas turbine or a steam turbine. 
However, other systems such as an aircraft engine, a locomotive or any other 
electrical, chemical or mechanical systems, where it is desirable to predict a 
maintenance schedule and costs for performing future service events of a product, 
may be used with the teachings of this disclosure. In the power generation equipment 
10 scenario, the maintenance requirements for the gas and steam turbine units depend on 
O several operational factors, such as: (1) unit model; (2) design features of parts in the 

u unit; (3) environment that unit is operating in; (4) type of fuel used; (5) number of 

*!r hours of operation; (6) number of times the unit is started in a month; (7) number of 

fl! trips, where a trip is a sudden and unexpected stoppage of the unit, where a variable 

jfjl5 may be utilized to equate one trip to a predetermined number of starts or a portion of a 
f start; (8) reliability needs; (9) utilization needs; and (10) reserve requirements. 

H Although this disclosure is described with reference to these operational factors, one 

K of ordinary skill in the art will recognize that other factors could be used with the 

y teachings of this disclosure. 

20 The method for predicting the maintenance schedule and costs of future 

service events of power generation equipment takes these operational factors into 
account in determining a schedule setting forth the timing of the service events for the 
units and costs associated with performing these events. After obtaining the schedule 
of the service events and the costs associated therewith, one can predict the costs and 

25 price of a long term service agreement for one of these power generation units. A 
more detailed explanation of determining the schedule and predicting the costs of 
performing the scheduled events is set forth below. 
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Determining Schedule: 

This determination comprises coming up with a detailed list of all service 
events for a power generation unit that are expected to occur in the future on a long 
term service agreement contract along with their dates. Similar determinations may 
5 be made for many other types of equipment, such as aircraft engines for example. 
Based on the contract information, which includes the customer sites, the units to be 
maintained, their operating conditions etc., the future inspections that have to be 
performed on each unit in the contract are generated as follows. 

1. Calculate the factored fired hours (FFH) and factored fired 
10 starts (FFS) based on the operating conditions and the unit model; 

2. At the end of each time period, check to see if any design limits 
on a part have been exceeded; and 

3. If so, schedule an appropriate maintenance inspection. 

In this case, the factored fired hours and factored fired starts are normalized 
15 measures of the operating life of the parts of the power generation equipment based 
on the operating conditions. The factored fired hours correspond to normal operating 
conditions and are associated with a factored fired hours design limit. The factored 
fired starts correspond to the operating conditions when the unit is first started, since 
the start-up conditions affect the life of the part. The predicted inspections on all the 
20 units are sequenced by the time of their occurrence. Any other events that are 
necessary for purchasing spare parts, etc. are also included in the schedule. The 
schedule is adjusted to ensure that the inspections do not fall in months with peak 
customer demands. The system-generated schedule is then displayed to a user for 
approval. The user can then manually adjust this schedule before his/her approval. 

25 The computations for FFH and FFS will vary depending on the manufacturer 

and model of the power generation equipment being evaluated. Further, the FFH and 
FFS are part specific, meaning that each individual part or drawing number within the 
unit/system has it's own calculated FFH and FFS. In evaluating the FFH and FFS, in 
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general, a number of factors are taken into consideration. For example, a typical FFH 
determination takes into consideration factors such as: the modes of operation, such as 
the wet and dry modes; the types of fuels, such as gas, distillate and heavy fuels; the 
types and percentages of the injection modes, such as water or steam; the operating 
hours using the various fuels; and the operating hours at various load levels, such as at 
peak load and at a reduced load. Similarly, a typical FFS determination takes into 
consideration factors such as: the number of start/stop cycles for various starting 
conditions, such as emergency starts, fast load starts, partial load starts, peak load 
starts, base load starts; the number and severity of trips; the actual hours of operation, 
and the hours of operation on various fuels; the number of starts using various fuels, 
such as gas, distillate fuel and heavy fuel; and the types of injection modes. Thus, 
these determinations are utilized to provide a cumulative measure of FFH and FFS to 
determine if a design limit has been exceeded. 

Predicting Costs: 

As mentioned above, this part of the disclosure comprises predicting the cost 
and price of a long term service agreement contract. This part takes the detailed 
schedule generated by the earlier procedure as input and then sequentially simulates 
the execution of each event in the schedule. For every event in the schedule, it does 
the following. 

1. Determines all the parts that have to be replaced; 

2. Checks to see if the spare parts for replacement are available in 
the inventory pools established to service this contract; 

3. Determines any new spare parts that need to be purchased; 

4. Schedules the parts that come out of a unit for repair 
(refurbishment) if required; 

5. Determines all the services that need to be performed during 
the event; 
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6, Estimates any risks that are associated with the event; and 

7. Computes all costs and prices that are associated with the event 
including those for parts, services, repairs and risks. 

The numbers for all the events are then aggregated to get the costs and prices 
5 for the entire long term service agreement. A flowchart explaining the above- 
described maintenance schedule and costs prediction is set forth in Figs. 4-7. 

Referring to Fig. 4, a user of the computer system 10 (Fig. 1) initiates the 
maintenance schedule and cost prediction process by entering data through the 
input/output devices 18 and 20 and viewing the display 22 (Step 90), The data 
r40 includes the configuration information of the product for which the prediction is being 
'M generated. The user then processes a mobilization event, which includes entering data 

f J related to the service contract to initiate the scheduling process (Step 92). The system 

jjy 28 (Fig. 2) then calculates the predicted maintenance event schedule for the product 

(Step 94), as will be described in more detail below. Once the predicted maintenance 
e" 15 event schedule is determined for the product, the predicted schedule may be 
1^ optionally added to a master event schedule that incorporates the predicted schedules 

from a plurality of products (Step 96). For example, the master event schedule may 
O be utilized to maintain and analyze the maintenance schedules for a portfolio of 

products, where the portfolio of products represents a single contract with a single 
20 customer or multiple contracts with multiple customers. The system 28 then takes the 
predicted maintenance event schedule for the product, or the master event schedule 
for the portfolio of products, and calculates the event costs (Step 98), as will be 
discussed in more detail below. The system 28 processes this information until the 
end of the term of the contract is reached, and then determines the aggregated 
25 maintenance schedule and costs (Step 100). 

Referring to Fig. 5, in one preferred embodiment of calculating the schedule 
for power generation equipment, the system 28 reads the operating conditions for a 
predetermined time period, such as a month, in order to determine the affect of those 
operating conditions on the life cycle of the parts in the product (Step 102). In this 
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case, the predetermined time period is a portion of the term of the service contract. 
The predetermined time period may be any time period up to the term of the service 
contract, but incremental portions of the entire term are preferred for ease of 
scheduling and processing. Also in this example, the operating conditions include the 
5 operating hours of the predetermined time period, the number of times the equipment 
was started, as well as the operating conditions during the operating hours. The 
system 28 then obtains the operating hours and starts since the last scheduled 
maintenance event for each part in the product (Step 104). It should be noted that the 
last scheduled maintenance event may be different for each part in the product, and 
10 this data is stored and recalled from the product data 30 within the mass storage 
device 26. The system 28 also obtains the cumulative operating hours and starts prior 

□ to the last scheduled maintenance event for each part in the product (Step 106) from 

Ci the product data 30. 

00 Using these numbers, the system 28 can determine a normalized measure of 

Hi 5 operating hours since the last repair, as well as a normalized cumulative total 
!" operating hours (which include operating hours prior to the last repair), for each part. 

H In this case, the operating hours are normalized as factored fired hours (FFH), which 

W are the hours of operation of the equipment under normal operating conditions. 

H Further the equipment starts are normalized as factored fired starts (FFS). The 

ttO operating hours and starts are normalized because the different conditions experienced 
by power generation equipment during normal operating conditions and starts each 
have a different affect on the life cycle of each part in the unit, based on the unique 
characteristics of each part. The FFH and FFS design limits generally correspond to 
the expendable life of a part, where each part has a first expendable life under 
25 continuous, normal operating conditions and a second expendable life based on the 
number of starts to which the part is exposed. Thus, each part has an FFH design 
limit and an FFS design limit. One skilled in the art will realize, however, that many 
other measures may be utilized to determine when a part needs maintenance and when 
a part needs to be replaced based on the cumulative operating conditions and repair 
30 history of the part. 
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The system 28 then evaluates the total operating hours since the last scheduled 
maintenance event, and the cumulative operating hours, against the design limit for 
each part in the product (Step 108). The system 28 then queries whether the design 
limit for the part has been reached (Step 110). 

Each part has a design limit that includes a repair limit and a replacement 
limit. The repair limit is the number of operating hours the part may experience 
before it needs to be taken out of the product and repaired. The replacement limit is 
the maximum number of operating hours, or the maximum number of times, that a 
part may experience. For example, a turbine blade may have design limits of 24,000 
operating hours, 50 starts and 2 total repairs or refurbishments. As such, the turbine 
blade may be used for a maximum of 72,000 operating hours or 150 starts, both 
including 2 repairs. Thus, after experiencing operating conditions that equate to the 
24,000 hour or 50 start design limit, a new turbine blade, meaning one that was 
installed with cumulative operating time and starts of zero, needs to be removed from 
the product and repaired. Further, after experiencing operating conditions that 
cumulatively total the equivalent of 72,000 hours or 150 starts, each including 2 
repairs, or after experiencing 2 repairs and the equivalent of 24,000 operating hours or 
50 starts since the last repair, the turbine blade can no longer be repaired and must be 
replaced with a new part. 

If a design limit has been reached, then the system 28 adds an event to the 
maintenance schedule for the product and updates the cumulative totals, such as the 
cumulative operating hours, the cumulative starts and the cumulative number of 
repairs (Step 112). After updating the schedule in Step 112, or if the design limit was 
not reached in Step 110, then the system 28 queries whether the end of the term of the 
contract has been reached (Step 114). If the end of the term has not been reached, 
then the system returns to Step 102 and repeats the process for the next predetermined 
time period, or month in this case (Step 116). If the end of the term has been reached, 
then the system 28 adds an end of term maintenance event to the schedule for the 
product (Step 118). 



-15- 



RD-28,035/USA 



The user is then able to review the schedule and make any required changes 
(Step 120). For example, the user may change the schedule maintenance events to an 
earlier date to avoid such problems as holidays or manpower or parts shortages. The 
system 28 then queries whether the maintenance event schedule has been manipulated 
(Step 122). If the schedule has been adjusted by the user, the system 28 determines 
the impact upon the schedule and reforecasts the schedule as required (Step 124). For 
example, if a predicted maintenance event has been moved to an earlier date, then 
future maintenance events would typically have to be moved to earlier dates in order 
not to exceed any design limits. If the schedule has not been adjusted, then the system 
28 establishes the final maintenance event schedule for the product (Step 126) and 
optionally adds it to the master event schedule (Step 128). 

Referring to Fig. 6, in one preferred embodiment of calculating the 
maintenance event costs for power generation equipment, the system 28 uses the 
simulator 62 to process the first event on the final maintenance event schedule for the 
product or portfolio (Step 130). The system 28 then queries whether the event is an 
end of term event (Step 132). If the event is not an end of term event, then the system 
28 determines the type of the event (Step 136), and develops a list of the parts to be 
replaced (Step 138) and the services to be performed (Step 140), along with the 
associated parts and service risks, respectively, based on the event type. For example, 
the simulator 62 may access the service data 58, the risk data 54 and the product data 
30 to extract the information relevant to the event type. Using this data the system 
determines the parts to be replaced and the services to be performed, as well as the 
associated costs and risks. Using the list of parts to be replaced, the system 28 then 
goes to one or more predetermined pools of inventory to determine the availability of 
the part (Step 142). 

For example, there may be one or a plurality of customer inventory pools of 
parts where only the designated customer may have access to the inventory. Also, 
there may be a service contractor inventory of parts that may be used to service any 
customer within the service contractor's portfolio of service agreements. Further, the 
service agreement may designate a predetermined order of searching the one or more 
inventory pools to get the part. 
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The system 28 then queries whether the part is available within the designated 
inventory pool (Step 144). If the part is not in the first predetermined inventory pool, 
the system then queries whether all inventory pools have been searched (Step 146). If 
so, the system then processes an order to buy the part into a predesignated inventory 
pool (Step 148). For example, in the service agreement, the customer may want any 
purchased parts to be entered into the customer inventory pool so that the customer 
has exclusive access to these parts. In such a case, for example, the cost of replacing 
the part will be higher because access to the inventory of parts is restricted to the one 
customer as opposed to being shared by many customers. 

If all of the inventory pools have not been checked (Step 146), then the system 
searches for the part in the next inventory pool based on the predetermined order until 
the part is located or until all inventory pools have been searched (Step 150). Once 
the part is found or purchased, the part is removed from the inventory (Step 152) and 
the inventory is processed to determine the parts costs and risks associated with the 
event (Step 154). Further, the event identification and the product identification are 
recorded in an inventory register so that a history of the inventory transaction is 
maintained (Step 156). 

Referring to Fig. 7, once all parts are withdrawn from inventory, the simulator 
62 further processes the maintenance event by simulating the removal of the parts 
from the product (Step 158). The system then queries whether each of the parts can 
be repaired or refurbished (Step 160). Each part has a design limit for the number of 
times that the part can be repaired or refurbished. This repair design limit is stored as 
part of the product data 30 within the database 26. If repair is possible, then the 
system schedules the appropriate transaction to have the part repaired (Step 162). If 
repair is not possible, then the system simulates the purchase of a new part (Step 164). 
Then, the new or repaired part is returned to the inventory from which the 
replacement part was removed (Step 166). The system then simulates adding each 
replacement part to the product (Step 168) and queries whether this is the last part in 
the part list (Step 170). If more parts are on the list, then the system selects the next 
part in the list and repeats the process (Step 172). If there are no more parts in the list, 
then the system processes the services to determine the service cost and risk (Step 
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174). Optionally, a fee and a margin may be added to the parts and service costs and 
risks for the event (Step 176). At step 178, the system then returns to step 130 (Fig. 
6) to process the next event in the final maintenance schedule for the product. 

Returning to Fig. 6, if the system determines that the next event is an end of 
term event (Step 132), then the system processes the end of term event (Step 180). 
For example, the end of term event signals the end of the maintenance contract. At 
the end of the maintenance contract certain contract conditions may need to be 
satisfied, such as a required number of parts in inventory, a minimum remaining 
operating life on the parts within the unit, etc. These conditions may be analyzed and 
processed by the present system. After processing the end of term event for the 
product, the system queries whether or not there are any more final event schedules to 
be evaluated (Step 182). For example, additional final event schedules may be 
analyzed when estimating the costs of a service contract that includes a portfolio of 
products. If there are other final event schedules, then the system gets the next event 
schedule (Step 184) and begins processing (Step 130). If no more final event 
schedules are to be analyzed, then the system 28 aggregates the total cost of the 
service contract (Step 186). For ease of analysis, this aggregated cost includes total 
costs and a breakdown of the various parts and service costs and risks, as well as fees 
and margins, for each event in the maintenance schedule. 

The foregoing schematic drawings and flow charts show the architecture, 
functionality, and operation of a possible implementation of the system for predicting 
a maintenance schedule and costs for performing future service events of a product. 
In this regard, each block represents a module, segment, or portion of code, which 
comprises one or more executable instructions for implementing the specified logical 
function(s). It should also be noted that in some alternative implementations, the 
functions noted in the blocks may occur out of the order noted in the figures, or for 
example, may in fact be executed substantially concurrently or in the reverse order, 
depending upon the functionality involved. 

The above-described system and method for predicting a maintenance 
schedule and costs for performing future service events of a product comprise an 
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ordered listing of executable instructions for implementing logical functions. The 
ordered listing can be embodied in any computer-readable medium for use by or in 
connection with a computer-based system that can retrieve the instructions and 
execute them. In the context of this application, the computer-readable medium can 
be any means that can contain, store, communicate, propagate, transmit or transport 
the instructions. The computer readable medium can be, for example but not limited 
to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor 
system, apparatus, or device. An illustrative, but non-exhaustive list of computer- 
readable mediums can include an electrical connection (electronic) having one or 
more wires, a portable computer diskette (magnetic), a random access memory 
(RAM) (magnetic), a read-only memory (ROM) (magnetic), an erasable 
programmable read-only memory (EPROM or Flash memory) (magnetic), an optical 
fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). It 
is even possible to use paper or another suitable medium upon which the instructions 
are printed. For instance, the instructions can be electronically captured via optical 
scanning of the paper or other medium, then compiled, interpreted or otherwise 
processed in a suitable manner if necessary, and then stored in a computer memory. 

It is apparent that there has been provided in accordance with this invention, a 
system and method for predicting a maintenance schedule and costs for performing 
future service events of a product. While the invention has been particularly shown 
and described in conjunction with a preferred embodiment thereof, it will be 
appreciated that variations and modifications can be effected by a person of ordinary 
skill in the art without departing from the scope of the invention. 
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